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DETAILED ACTION 



Response to Arguments 



1 . Applicant's arguments filed 24 March 2003 have been fully considered but they are not 
persuasive, with regards to the § 112 rejections. Applicant has amended claims 1 and 7 in an 
attempt to distinguish the hierarchical network from the non-hierarchical network by requiring 
the hierarchical network "allows hierarchical routing control by which a route is searched for 
without referring to an entirety of address bits that identify a network." Examiner asserts that this 
limitation for hierarchical networks does not distinguish a non-hierarchical network as IPv4 and 
a hierarchical network as IPv6 since IPv4 networks allow hierarchical routing control by which a 
route is searched for without referring to an entirety of address bits that identify a network, as is 
evidenced in Krishnan (USPN 6,157,950). Krishnan discloses that the IPv4 address is 
hierarchical since the address can be broken into network addresses, subnet addresses, and 
computer addresses (col. 5, line 38-col. 6, line 8). Krishnan further discloses that routers in IPv4 
search for a destination route using only a portion of the IP address (col. 5, line 38-col. 6, line 8). 
Taken as a whole, Krishnan suggests that in IPv4 a packet will be routed using the network 
address until a router serving the destination network is reached, at which point routing continues 
using the subnet address and finally the computer address. As broadly interpreted, Krishnan 
discloses that IPv4 allows hierarchical routing control by which a route is searched for without 
referring to an entirety of address bits that identify a network since routing can be performed 
using the network address and routing can also be performed using the subnet address where an 
entirety of address bits that identify a network is taken to be only the address bits that identify the 
network address, but not the subnet address. In addition, even if the limitation were to read on an 
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IPv4 network, calling an IPv4 network non-hierarchical is repugnant to the term's common 
usage. An IPv4 address contains a network block and a host block. This format is hierarchical in 
structure with the hierarchy containing two levels, namely the network and the host. For 
example, Krishnan refers to an address containing a network block and a host block as 
hierarchical (col. 5, lines 38-53). Thus, the examiner contends that referring to an IPv4 address 
as non-hierarchical is repugnant to the term's common usage. 

2. Applicant's arguments with respect to claims 1-12 have been considered but are moot in 
view of the new ground(s) of rejection. 

Claim Rejections - 35 USC § 112 

3. The following is a quotation of the first paragraph of 35 U.S. C. 112: 

The specification shall contain a written description of the invention, and of the manner and process of making 
and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it 
pertains, or with which it is most nearly connected, to make and use the same and shall set forth the best mode 
contemplated by the inventor of carrying out his invention. 

4. Claims 1-12 are rejected under 35 U.S.C. 1 12, first paragraph, as containing subject 
matter which was not described in the specification in such a way as to enable one skilled in the 
art to which it pertains, or with which it is most nearly connected, to make and/or use the 
invention. Prior art rejections will be made according to the examiner's best interpretation at the 
time of examination. 

5. Regarding claims 1-12, the applicant stated in the specification that the invention's 
intended use is as a transition between IPv4 and IPv6 networks. This statement allows for 
confusion because in the claims the applicant specifies the invention's intended use is as a 
transition between hierarchical and non-hierarchical networks. It is assumed that the IPv4 
network is the claimed non-hierarchical network; however, in a broad context, an IPv4 network 
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could be viewed as a hierarchical network containing two levels (one level being the inter-router 
network and the other level being the host network). Since an IPv4 network could be viewed as 
hierarchical, there is confusion between the specification and the claims, and thus the claims are 
not enabling. For purposes of this office action, a non-hierarchical network is given broad 
interpretation, including an IPv4 network. 

Claim Rejections - 35 USC §103 

6. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

7. Claims 1-5 and 7-1 1 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Krishnan (USPN 6,157,950) in view of Callon et al (USPN 5,251,205) in further view of Callon 
(Callon, R. "Routing Aspects of IPv6 Transition." Networking Working Group RFC 2185. 
September 1997) in further view of Gilligan (Gilligan, R. "Transition Mechanisms for IPv6 
Hosts and Routers." Networking Working Group RFC 1933. April 1996). 

8. Regarding claims 1 and 7, Krishnan discloses that the Internet is a "heterogeneous 
collection of many computer networks interconnected by devices, such as 'bridges' and 'routers' 
that enable computers on one network to communicate with computers on other networks" (col. 
3 lines 52-57). The hierarchical structure of an IP address enables an IP datagram (IP packet) to 
be routed from one network to another network, even if the sending node does not know the path 
to the destination node. Each IP address is hierarchical because it consists of two main parts: the 
network ID and the node ID. The network ID distinguishes one network from the plurality of 
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networks in the inter-network. The node ID distinguishes one node from the plurality of other 
nodes within a network (col. 4 line 37- col. 6 line 8). Within a network, all communication 
between nodes is done solely on the basis of the node ID. The network ID is used when a node in 
one network communicates with a node on a separate network. In this scenario, the source node 
routes the packet to a "gateway node" which connects the network to the inter-network. The 
gateway node uses the network ID to determine in which network the destination node is located 
and to forward the packet to the gateway node of the destination network. The destination 
gateway node then forwards the packet to the node with the node ID contained in the destination 
address. Thus Krishnan discloses assigning a network a hierarchy number (network ID) that 
corresponds to a hierarchy number (network ID) in the hierarchical network (internet or inter- 
network); using the virtual hierarchy number of a packet to be relayed at a router (gateway node) 
located at an entrance from the network to the hierarchical network when the packet is to be 
relayed between networks via the hierarchical network; performing a hierarchical routing control 
by the virtual hierarchy number within the hierarchical network; and ignoring the virtual 
hierarchy number of the packet to be relayed at a router located at an exit from the hierarchical 
network to the destination network (Fig. 3; col. 3, lines 52-57; and col. 4, line 37- col. 6, line 8). 
Krishnan possibly does not disclose assigning the non-hierarchial network a virtual hierarchy 
number that depends on a hierarchy number of a portion of the hierarchical network to which the 
non-hierarchical network is connected, attaching the virtual hierarchy number to a packet to be 
relayed at a router located at an entrance from a network to the hierarchical network when the 
packet is to be relayed between networks via the hierarchical network, and removing the virtual 
hierarchy number from the packet to be relayed at a router located at an exit from the 
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hierarchical network to the destination network. Callon ( c 205) discloses that it is well known in a 
network comprising two local networks ("non-hierarchical" networks) connected by another 
network ("hierarchical" network), where the local networks and the hierarchical network support 
different protocols, to attach a virtual hierarchy number to a packet to be relayed at a router 
located at an entrance from a network to the hierarchical network when the packet is to be 
relayed between networks via the hierarchical network and removing the virtual hierarchy 
number from the packet to be relayed at a router located at an exit from the hierarchical network 
to the destination network (col. 3, lines 13-41). Callon ('205) does this in order to allow the 
packet to be relayed across a hierarchical network using the protocol of the hierarchical network. 
It would have been obvious to one of ordinary skill in the art at the time of the invention to attach 
the virtual hierarchy number to a packet to be relayed at a router located at an entrance from a 
network to the hierarchical network when the packet is to be relayed between networks via the 
hierarchical network and remove the virtual hierarchy number from the packet to be relayed at a 
router located at an exit from the hierarchical network to the destination network in order to 
allow a packet to be relayed across the hierarchical network when the non-hierarchical networks 
do not support the protocol of the hierarchical network. Callon ('205) further discloses that the 
virtual hierarchy number (header of protocol B) includes routing information specific to the 
hierarchical network which would allow the packet to be forwarded to a gateway router servicing 
the destination end station (col. 1, lines 5-50 and col. 2, lines 15-25). Since a packet being routed 
on the hierarchical network needs to arrive at the correct hierarchical router servicing the 
destination end station, and since the address of a gateway router depends on a specific network 
address (virtual hierarchy number) it is obvious that Callon ('205) assigns the local networks a 
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virtual hierarchy number that depends on a hierarchy number of a portion of the hierarchical 
network to which the local network is connected. Thus it would have been obvious to one of 
ordinary skill in the art at the time of the invention to assign the non-hierarchial network a virtual 
hierarchy number that depends on a hierarchy number of a portion of the hierarchical network to 
which the non-hierarchical network is connected in order to allow the non-hierarchical packet to 
be routed to the correct router in the hierarchical network. Callon (RFC 21 85) and Gilligan both 
teach implementing a mixed environment of IPv6 and IPv4 networks where an IPv4 network is 
taken to be non-hierarchical and an IPv6 network is taken to be hierarchical. IPv6 differs greatly 
from IPv4 with regards to the size of IP addresses. IPv6 addresses are 128 bits and IPv4 
addresses are 32 bits (Gilligan: page 3, section 2). In order to operate IPv6 and IPv4 networks 
side-by-side, an addressing method has been developed dubbed IPv4-Compatible IPv6 
addressing in which IPv4 addresses are incorporated into IPv6 addresses (page 3, section 2 and 
page 4, section 3.1). With this method, gateway nodes run "dual IP layer" in which the gateway 
node is capable of supporting both IPv4 and IPv6 datagrams. By packing an IPv4 address as an 
IPv6 address using an IPv4-Compatible IPv6 address (address which incorporates a valid IPv4 
address into the lower 32 bits of an IPv6 address) or extracting an IPv4 address from an IPv4- 
Compatible IPv6 address, the gateway is able to convert IPv4 packet addresses to IPv6 addresses 
and vice versa (Gilligan: page 15, section 4.3, page 2 section 1 .2 "Types of IPv6 Addresses" and 
Callon (RFC 2185): page 1, section 2 and page 3 section 3.1). It should be noted that IPv6 
addresses follow the IP address method of being hierarchical by having a computer ID and 
network ID. Callon (RFC 2185) in view of Gilligan discloses that an IPv4-Compatible IPv6 
address is distinct from other IPv6 addresses because it has the network IDs zeroed and the IPv4 
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address placed in the computer ID section. Thus, the IPv4-Compatible IPv6 address can be 
viewed as having a network ID of 0. As such, Callon (RFC 2185) and Gilligan disclose attaching 
the virtual hierarchy number (the IPv6 network ID section in an IPv4-Compatible IPv6 address) 
to a packet to be relayed at a router located at an entrance from an IPv4 network to an IPv6 inter- 
network when the packet is to be relayed between IPv4 networks via the IPv6 inter-network and 
removing the virtual hierarchy number (extracting the IPv4 address) from the packet to be 
relayed at a router located at an exit from the IPv6 inter-network to the IPv4 network. It would 
have been obvious to one of ordinary skill in the art to attach a virtual hierarchy number to a 
packet to be relayed at a router located at an entrance from an IPv4 network to an IPv6 inter- 
network when the packet is to be relayed between IPv4 networks via the IPv6 inter-network and 
to remove the virtual hierarchy number from the packet to be relayed at a router located at an exit 
from the IPv6 inter-network to the IPv4 network in order to allow an IPv4 packet to be 
transported over an IPv6 inter-network. It would also be obvious in view of Callon ('205), above, 
to assign the non-hierarchial network a virtual hierarchy number that depends on a hierarchy 
number of a portion of the hierarchical network to which the non-hierarchical network is 
connected in order to allow the non-hierarchical packet to be routed to a specific router in the 
hierarchical network. 

9. Regarding claims 2 and 8, referring to claims 1 and 7, Gilligan and Callon (RFC 2185) 
disclose having an address of the IPv4 network be accommodated in an interface identification 
information block (computer ID) of an address format of the IPv6 network, and the virtual 
hierarchy number be accommodated in a hierarchy information block of the address format of 
the IPv6 network for said hierarchical routing control and transmitting routing information 
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(Gilligan: page 15, section 4.3, page 2 section 1.2 "Types of IPv6 Addresses" and Callon (RFC 
2185): page 1, section 2 and page 3 section 3.1) where the virtual hierarchy number is 0. Gilligan 
and Callon (RFC 2185) do this in order to make IPv4 addresses compatible with IPv6 addresses. 
Callon ( c 205) suggests having the virtual hierarchy number vary depending on a hierarchy 
number of a portion of the hierarchical network to which the non-hierarchical network is 
connected in order to allow the non-hierarchical packet to be routed to a specific router in the 
hierarchical network. 

10. Regarding claims 3 and 9, referring to claims 2 and 8, Gilligan discloses that in a gateway 
node two routing tables are kept, one for the IPv6 address and one for the IPv4 address (Gilligan: 
page 5 sec. 3.2.1). This is done so that the gateway node can keep an accurate routing table of 
IPv6 addresses and IPv4 addresses. However, it is obvious that the router must be able to 
transition between both tables in order to be capable of handling IPv4-Compatible IPv6 
addresses. An IPv4-Compatible IPv6 address is recognizable as an IPv4-Compatible IPv6 
address through its network ID block which specifies the network to which the packet belongs. 
The network ID indicates an IPv4 or IPv6 compatible network, for instance a network ID of 0 
indicates an IPv4 network. In order to make IPv6 routing decisions, the router only needs to use 
the network ID (hierarchical information block) of the IPv4-Compatible IPv6 address, but in 
order to transition from IPv6 to IPv4, the router must be able to recognize the packet as an IPv4- 
Compatible IPv6 address through the network ID (hierarchical information block) and then use 
the IPv4 address stored in the computer information block (interface identification block). Thus, 
as broadly interpreted, Gilligan discloses having each router of the IPv6 network have a routing 
table that performs routing said hierarchical routing control by using only the hierarchical 
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information block as a key (routing IPv6 packets based on network ID), and a conventional 
routing table that performs routing search by using the hierarchical information block 
hierarchical information and the interface identification information block as keys (IPv4 
conversion, identifying the packet as one containing an IPv4 address and routing according to 
that address) (Gilligan: page 5 sec. 3.2.1). It would have been obvious to one of ordinary skill in 
the art to have a router of the IPv6 network have a routing table that performs a routing search by 
using only the hierarchical information block as a key, and a conventional routing table that 
performs routing search by using the hierarchical information block hierarchical information and 
the interface identification information block as keys in order to allow the router to route IPv6 
packets and transition between IPv6 and IPv4 packets. 

1 1 . Regarding claims 4 and 10, referring to claims 3 and 9, Gilligan discloses that in a 
gateway node two routing tables are kept, one for the IPv6 address and one for the IPv4 address 
(Gilligan: page 5 sec. 3.2.1). This is done so that the gateway node can keep an accurate routing 
table of IPv6 addresses and IPv4 addresses. However, it is obvious that the router must be able to 
transition between both tables in order to be capable of handling IPv4-Compatible IPv6 
addresses. An IPv4-Compatible IPv6 address is recognizable as an IPv4-Compatible IPv6 
address through its network ID block which specifies the network to which the packet belongs. 
The network indicates an IPv4 or IPv6 compatible network, for instance a network ID of 0 
indicates an IPv4 network. In order to make IPv6 routing decisions, the router only needs to use 
the network ID (hierarchical information block) of the IPv4-Compatible IPv6 address, but in 
order to transition from IPv6 to IPv4, the router must be able to recognize the packet as an IPv4- 
Compatible IPv6 address through the network ID (hierarchical information block) and then use 
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the IPv4 address stored in the computer information block (interface identification block). Thus, 
Gilligan discloses having each router of the hierarchical network use the hierarchical routing 
table when relaying a packet between the hierarchical network and another hierarchical network 
(Gilligan: page 5 sec. 3.2.1). It would have been obvious to one of ordinary skill in the art to 
have each router of the hierarchical network use the hierarchical routing table when relaying a 
packet between the hierarchical network and another hierarchical network in order to allow the 
router to route IPv6 packets through the inter-network. 

12. Regarding claims 5 and 11, referring to claims 3 and 9, Gilligan discloses that in a 
gateway node two routing tables are kept, one for the IPv6 address and one for the IPv4 address 
(Gilligan: page 5 sec. 3.2.1). This is done so that the gateway node can keep an accurate routing 
table of IPv6 addresses and IPv4 addresses. However, it is obvious that the router must be able to 
transition between both tables in order to be capable of handling IPv4-Compatible IPv6 
addresses. An IPv4-Compatible IPv6 address is recognizable as an IPv4-Compatible IPv6 
address through its network ID block which specifies the network to which the packet belongs. 
The network indicates an IPv4 or IPv6 compatible network, for instance a network ID of 0 
indicates an IPv4 network. In order to make IPv6 routing decisions, the router only needs to use 
the network ID (hierarchical information block) of the IPv4-Compatible IPv6 address, but in 
order to transition from IPv6 to IPv4, the router must be able to recognize the packet as an IPv4- 
Compatible IPv6 address through the network ID (hierarchical information block) and then use 
the IPv4 address stored in the computer information block (interface identification block). Thus, 
as broadly interpreted, Gilligan discloses having each router of the hierarchical network use the 
conventional routing table when relaying a packet from the hierarchical network to the non- 
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hierarchical network, and from the non-hierarchical network to the hierarchical network 
(Gilligan: page 5 sec. 3.2.1). It would have been obvious to one of ordinary skill in the art to 
have each router of the hierarchical network use the conventional routing table when relaying a 
packet from the hierarchical network to the non-hierarchical network, and from the non- 
hierarchical network to the hierarchical network in order to allow the router to transition between 
IPv6 and IPv4 packets. 

13. Claims 6 and 12 are rejected under 35 U.S.C. 103(a) as being unpatentable over Krishnan 
(USPN 6,157,950) in view of Callon et al (USPN 5,251,205) in further view of Callon (Callon, 
R. "Routing Aspects of IPv6 Transition." Networking Working Group RFC 2185. September 
1997) in further view of Gilligan (Gilligan, R. "Transition Mechanisms for IPv6 Hosts and 
Routers." Networking Working Group RFC 1933. April 1996.) applied to claims 5 and 1 1 above, 
and further in view of Miki (USPN 6,046,999). 

14. Regarding claims 6 and 12, referring to claims 5 and 11, Krishnan in view of Callon 
('205) in further view of Callon (RFC 2185) in further view of Gilligan possibly does not 
disclose that the router located at a boundary of the IPv4 network and the IPv6 network 
recognizes a packet relay from the IPv4 network to the IPv6 network, and from the IPv6 network 
to the IPv4 network, by using a receiving interface name and a transmission interface name when 
relaying the packet. Miki discloses a router that uses a "switch port number. . .which is set for 
each of various interfaces such as the ATM interface, the IP-support frame relay interface, etc. 
The IP controller... recognizes the port with the switch port number" (col. 7, lines 52-54). Miki's 
router, which recognizes the format of data of an information packet based upon the port at 
which it arrived, has the benefit of "providing] a router apparatus which can support various 
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types of communications." (col. 2, lines 59-61) As broadly defined, the serial number, as 
described above, is interpreted as an "interface name." Thus it would have been obvious to one 
of ordinary skill in the art of routers at the time of the invention to have a router located at a 
boundary of the IPv4 network and the IPv6 network recognize a packet relay from the IPv4 
network to the IPv6 network, and from the IPv6 network to the IPv4 network, by using a 
receiving interface name and a transmission interface name when relaying the packet in order to 
allow the "mixed environment" router to "support various types of communications" by 
recognizing from the port at which the data arrived whether it was an IPv6 type packet to be 
converted to an IPv4 format or vice versa. 

Conclusion 

15. The prior art made of record and not relied upon is considered pertinent to applicant's 
disclosure: Perlman et al (USPN 5,557,745) see col. 5, lines 40-62 which detail encapsulating a 
packet to be routed over a "foreign protocol." 

16. Applicant's amendment necessitated the new ground(s) of rejection presented in this 
Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 
Applicant is reminded of the extension of time policy as set forth in 37 CFR 1 . 1 36(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within TWO 
MONTHS of the mailing date of this final action and the advisory action is not mailed until after 
the end of the THREE-MONTH shortened statutory period, then the shortened statutory period 
will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 
CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, 
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however, will the statutory period for reply expire later than SIX MONTHS from the date of this 
final action. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Daniel J. Ryman whose telephone number is (703)305-6970. The 
examiner can normally be reached on Mon.-Fri. 7:00-5:00 with every other Friday off. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Huy Vu can be reached on (703)308-6602. The fax phone numbers for the 
organization where this application or proceeding is assigned are (703)308-6743 for regular 
communications and (703)308-9051 for After Final communications. 

Any inquiry of a general nature or relating to the status of this application or proceeding 
should be directed to the receptionist whose telephone number is (703)305-3900. 



Daniel J. Ryman 
May 2, 2003 




Daniel J. Ryman 
Examiner 
Art Uni^95 



